Most modern application program modules, such as word processing program modules, are enhanced by designers from time to time to add features to the program module and to correct bugs in the program module. An enhanced or corrected program module is typically assigned a new version number to indicate that changes have been made to the program module. For example, the first version of a program module may be labeled version 1.0 and a later-released version that corrects some of the bugs in version 1.0 may be labeled version 1.1.
Adding new features to a program module or correcting bugs in a program module may require a change in the format of files saved by the program module. The file format is the structure that defines the manner in which the file is stored and laid out on a computer screen or in print. A file format may be fairly simple and common, such as the file format for files stored as ASCII text. A file format may also be quite complex and include various types of control instructions and codes used by printers or other external devices. Some further examples of file formats include Rich Text Format (RTF), Document Content Architecture (DCA), Data Interchange Format (DIF), Drawing Interchange Format (DXF), Tag Image File Format (TIFF), and Encapsulated PostScript Format (EPSF). Different versions of an application program module will typically have slightly different file formats due to added features or corrections of bugs in more advanced versions.
Any program module that changes its file format when releasing a new version has to deal with compatibility issues between different versions of the program module. More particularly, compatibility issues mean backwards compatibility and forwards compatibility. In describing backwards compatibility and forwards compatibility, it is helpful to consider two versions of a program module which will be referred to as version (n) and version (n'). For sake of example, version (n) is a version of a program module that has been released prior to version (n'). Backwards compatibility is the ability of version (n') of a program module to read files created by version (n) of the program module. In other words, backwards compatibility is the ability of a version of a program module to read files created by prior-released versions of the program module. On the other hand, forwards compatibility is the ability of version (n) of a program module to read files created by version (n') of the program module. In other words, forwards compatibility is the ability of a version of a program module to read files created by subsequently-released versions of the program module.
All program modules should have strong backwards compatibility because, at the time version (n') is released, the software designers theoretically know all there is to know about version (n). Thus, backwards compatibility is sometimes simply an issue of writing conversion code. However, if version (n) includes serious bugs in writing or saving files, then it may be difficult to write conversion code because, in essence, all of the serious bugs must be replicated in the conversion code. Thus, there is a need in the art for a method and system for providing backwards compatibility that does not require writing complicated and detailed conversion code.
In addition to seeking backwards compatibility, software designers seek forwards compatibility because breaking forwards compatibility makes it difficult for users to have mixed shops. A mixed shop is an environment in which users are operating different versions of a program module. For instance, in a mixed shop, some users may be using version (n) of a program module, some users may be using version (n') of the program module, some users may be using version (n") of the program module, etc. If a program module is not forwards compatible, then a user operating version (n) may not be able to read files that have been edited by a user operating version (n'). Thus, forwards compatibility is particularly important to mixed shop users.
To maintain forwards compatibility, some program modules have internal mechanisms that allow a version to recognize that a given file is too "advanced" to be opened. Typically, forwards compatibility is maintained by storing a version stamp, or other similar data property, with a file. The version stamp indicates which version of the program module last stored the file.
A version of a program module also typically includes a numerical value which indicates the highest version stamp that a file can have and still be opened by that particular version. This numerical value will be referred to herein as the "too advanced" value. If the version stamp of a file is higher than the "too advanced" value, then it is too "advanced" for that particular version to open. For example, suppose version (n') of a program module stores files with a version stamp equal to 100. Before version (n) attempts to open one of these files, version (n) compares its "too advanced" value with the version stamp of the file, i.e., 100. If the "too advanced" value of version (n) is less than this version stamp, then version (n) cannot open the file. On the other hand, if the "too advanced" value is greater than or equal to the version stamp, then version (n) can open the file.
Typically, if a file is determined to be too "advanced" to be opened, a separate external converter is used to convert the file to an older format, i.e., a less "advanced" file format, which can be opened. Although the version stamp technique and external converter work well in many instances, it is not without its drawbacks.
One drawback of the version stamp technique is that even slight changes in the file format results in a higher version stamp. This new version stamp may be so large that previous versions of the program module may not be able to read files with the new version stamp. Thus, an external converter must be used to convert these files to a less "advanced" file format. The need to use external converters can be annoying to users, especially in mixed shops in which conversion of files may need to be performed frequently. Thus, there is a need in the art for a method and system for providing forwards compatibility that does not require the use of an external converter.
Another drawback of the version stamp technique is that the decision that a file stored by a new version can not be opened by an older version may be too harsh in certain circumstances. For example, it may be possible that the older version could open a file created by a newer version if certain features are disabled. In this example, insisting on converting a file with an external converter may be too harsh because the older version could instead simply disable certain features and open the file. Thus, there is a further need in the art for a method and system for providing forwards compatibility that accommodates minor changes in file format.
Another problem is that every version release has bugs. The program designers may decide that, for feature X, the bugs are sufficiently rare or unimportant that version (n) may confidently be released with feature X as is. However, the same program designers may anticipate that, in version (n'), feature Y might be implemented and depend on feature X. Therefore, it can be anticipated that the same bugs that were rare or unimportant in version (n), plus others that are not known, may turn out to be a problem in version (n'). Thus, two different versions of a program module may be incompatible with respect to certain features. There is a need in the art for a method and system that allows version (n) to signal to version (n') that version (n) has edited a document, thus possibly corrupting the feature as far as version (n') is concerned. There is still a further need in the art for a method and system for version (n') to signal to version (n) that the document was edited by version (n') and certain features may be corrupt as far as version (n) is concerned.